home *** CD-ROM | disk | FTP | other *** search
/ Network Supervisor's Toolkit / Network Supervisor's Toolkit.iso / novell / nw386 / append-c.386 < prev    next >
Text File  |  1996-07-10  |  8KB  |  183 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7.  
  8.  
  9.  
  10.  
  11. Appendix C
  12. Benchmarking NetWare 386
  13.  
  14.  
  15.  
  16. Because of NetWare 386's modular design and its
  17. capability to allocate and deallocate memory as needed,
  18. it is naturally more open and efficient.  However, in
  19. light of these new, standard-setting features, it might
  20. be easy to take for granted the fact that NetWare 386 is
  21. a specialized networking operating system designed and
  22. coded to give optimum speed and performance.  For
  23. example, such things as reads and writes to the server
  24. hard disk are as fast or faster than reads or writes to
  25. a local disk.  Although benchmarks verify these and other
  26. performance issues, at least three factors particular to
  27. NetWare 386 must be accounted for during benchmarking. 
  28. If not, the benchmarks will not reveal the true
  29. performance capabilities of NetWare 386.  These three
  30. factors are as follows:
  31.  
  32.    ■ Memory Allocation: Let the NetWare 386 system
  33.      allocate the memory it needs to meet the
  34.      benchmarking test parameters.  To do this, run the
  35.      test once or twice before recording results.
  36.  
  37.    ■ Read-after-Write Verfication: Turn off this NetWare
  38.      386 automatic feature.  When benchmarking NetWare
  39.      against a system that does not perform read-after-
  40.      write verification, these extra reads (if not
  41.      disabled) put NetWare at a disadvantage. ■Salvagable Files: Turn off this NetWare 386
  42.      automatic feature.  By default, this feature
  43.      prevents deleted files from being purged so they
  44.      can be salvaged if necessary.  If this feature is
  45.      not disabled, benchmarking NetWare against a system
  46.      that does purge deleted files puts NetWare at a
  47.      disadvantage.  To disable this feature, set the
  48.      Immediate Purge of deleted files = ON
  49.  
  50. Memory Allocation
  51.  
  52. In versions of NetWare before 386, supervisors and system
  53. administrators allocated memory during installation for
  54. such resources as routing buffers, file and directory
  55. handles, and so forth.  The amount of memory allocated
  56. to these resources remained set while the remaining
  57. memory went to cache.  NetWare 386, however, requires
  58. about 2MB of memory for the initial OS, while the
  59. remaining memory becomes a pool of cache buffers to be
  60. dynamically allocated by resources as needed.  As NetWare
  61. 386 begins running, it allocates memory from this pool
  62. of cache buffers for any of the following resources:
  63.  
  64.    ■ Directory cache buffers
  65.    ■ File service processes
  66.    ■ Turbo FAT
  67.    ■ FAT
  68.    ■ Routing buffers
  69.    ■ Disk elevator size
  70.    ■ Directory hash tables
  71.    ■ Router/server advertising memory
  72.    ■ Maximum number of open files
  73.    ■ File locks
  74.    ■ Kernel processes
  75.    ■ Kernel semaphores
  76.    ■ TTS transactions
  77.    ■ NetWare Loadable Modules (NLMs)
  78.  
  79. Dynamic memory allocation allows the number of cache
  80. buffers needed for any of these resources to grow
  81. according to demand.  For example, cache buffers for
  82. Directory Table blocks are allocated according to demand,
  83. cache buffers for Turbo FATs are allocated when another
  84. file needs to be indexed, and so on. However, NetWare dynamic memory allocation also features
  85. a system of checks and balances.  Since dynamically
  86. allocated memory is never returned to the cache buffer
  87. pool unless the server goes down, these values are not
  88. allowed to grow without restriction.  Although the number
  89. of server processes and the memory required for those
  90. processes grow to meet demand, the server does not spawn
  91. a process immediately upon demand.
  92.  
  93. Instead, the server waits a few seconds to see if an
  94. existing process becomes available to service the demand. 
  95. If so, the server does not spawn a new process.  This
  96. restriction on growth ensures that the server does not
  97. permanently allocate memory because of sudden, infrequent
  98. peaks of server activity.
  99.  
  100. To summarize, NetWare 386 provides dynamic memory
  101. allocation for network resources.  However, depending on
  102. the number of resources that require memory and how much
  103. memory each resource requires, the dynamic memory
  104. allocation may take some time.  During this time, the
  105. NetWare 386 system may not be running at peak efficiency
  106. or speed.  When preparing to do benchmarks then, the
  107. NetWare 386 system should run a while before the
  108. benchmarking begins.  A good rule of thumb is to run the
  109. benchmarks a couple of times before tracking performance
  110. numbers.    
  111.  
  112. Read-after-Write Verification
  113.  
  114. Another factor to consider during benchmarking, read-
  115. after-write verification, has to do with matching
  116. functionality in the operating systems being tested. 
  117. NetWare 386 automatically performs a read-after-write
  118. verification on each piece of information written to the
  119. disk.  If the read-after-write is unsuccessful after
  120. several attempts, that disk block is marked as bad, and
  121. a feature of NetWare 386 called HotFix automatically
  122. writes the data to another part of the disk.
  123.  
  124. During a performance test in which you do a large number
  125. of writes to disk, NetWare 386 (with read-after-write
  126. verification) would be at a disadvantage against another
  127. system running without read-after-write verification. 
  128. To disable NetWare 386 read-after-write verification, go
  129. to the server console and, at the console prompt, type
  130. the following:
  131.  
  132.    SET ENABLE DISK READ AFTER WRITE VERIFY = OFF
  133. Salvage Files
  134.  
  135. As with read-after-write verification, Salvage Files, is
  136. a feature that could put NetWare 386 at a disadvantage
  137. during benchmarking.  NetWare 386 treats deleted files
  138. differently than did previous versions of NetWare.  In
  139. previous versions, a user could only recover the file (or
  140. files) deleted in the last ERASE or DELETE command. 
  141. Files deleted in earlier delete commands were lost
  142. forever.  NetWare 386 saves deleted files (and all
  143. information about those files) in their default directory
  144. until the server runs out of disk allocation blocks on
  145. the volume or until the user deliberately purges the
  146. deleted files.  If the user deletes the file's default
  147. directory too, the file is saved in a DELETED.SAV
  148. directory located in the volume's root directory.
  149.  
  150. In a testing environment in which you create and delete
  151. a large number of files in the same area over and over
  152. again, the NetWare 386 Salvage Files feature can
  153. adversely affect the dynamics of caching.  For example,
  154. when an operating system does not save a deleted file,
  155. it reallocates the space for that file to the next write. 
  156. It also makes the cache space for that deleted file
  157. available.  Thus, when the tests are run over and over
  158. again, the operating system allocates the same disk
  159. blocks and cache buffers over and over to perform the
  160. benchmarks.
  161.  
  162. Since NetWare 386 saves each deleted file, it must
  163. traverse the disk to perform the large repetition of
  164. writes that you do during benchmarking, reallocating a
  165. new disk block for each newly created file written to the
  166. disk.  This also means that cache buffers are taken away
  167. to create a new disk block.  Cache buffers are also
  168. flushed to disk and must be again added to cache for the
  169. next test.  So caching is really not being used as it
  170. ought to be.
  171.  
  172. If you are testing NetWare 386 against an operating
  173. system that does not save deleted files, disable the
  174. NetWare 386 Salvage Files feature.  To do this, type the
  175. following at the server console prompt:
  176.  
  177.    SET IMMEDIATE PURGE OF DELETED FILES = ON
  178.  
  179. When you set deleted files for immediate purging, you
  180. gain two things.  First, NetWare 386 won't have to
  181. reallocate new disk blocks for the files it has in
  182. memory, and second, it can make more efficient use of its
  183. caching capabilities.